Skip to content

Conversation

@marcusmoore
Copy link
Collaborator

@marcusmoore marcusmoore commented Oct 23, 2025

Currently, checking out multiple assets via the bulk checkout feature would result in individual emails being sent for each asset that was included in the checkout. This PR changes that behavior by sending one email that contains all assets that were checked out.


I attempted to make the resulting email as readable as possible so the new BulkAssetCheckoutMail itself does a lot of work to "bundle" up groups of assets.

  • If all of the assets checked out are from the same category then the EULA for that category is displayed once
  • If there are multiple assets from categories then the assets are grouped by category and their EULAs displayed at the end of each section.
  • The prompt to "click to accept" is dynamic and only appears if one or more of the assets require acceptance.

A few examples

Assets not requiring acceptance:
not-requiring-acceptance

"Bulk" checking out a single asset:
singular-item

Checking out assets where some items require acceptance:
full

Note that the last category "Displays" do not have a EULA so it is not displayed.


Technical

Here are some notes on how this is technically implemented:

  • Introduces a new event, CheckoutablesCheckedOutInBulk, and listener for that event.
    • The logic in here is similar to the existing CheckoutableListener but I separated it out since we're now dealing with an array of items and I didn't want to add a bunch of conditionals into the existing class.
  • I'm using (abusing?) the Context facade to facilitate some code paths by adding bulk_asset_checkout to the request's context in the controller layer and checking for that context in the existing CheckoutableListener to avoid sending individual notifications.
    • This approach was used to avoid making the CheckoutableListener more complex than it already is.
  • The new listener checks to see if notifications should be sent by seeing if any assets that were checked out have a EULA, requires acceptance, or have a category set to always send the email. If any of those conditions is true for one or more assets that were checked out then then the notification including all items is sent.

Additional notes

  • Webhooks still behave the same and are sent individually for each asset.
  • Subject line is "Assets checked out" unless someone only selected one asset to be "bulk" checked out. If that is the case then the subject line is "Asset checked out: {asset_tag}"
  • Images are not included in the email

Partially addresses #5947 (sends one email for the entire bulk checkout instead of individual emails for each asset). If acceptance is required the user will still need to accept each asset individually.

@marcusmoore
Copy link
Collaborator Author

@snipe you rightfully mentioned that checking out items from different categories with long EULAs might trigger some truncation or character limit.

Can you look at my overall approach in this PR and let me know if it is worth continuing down this path? If so, I'm tentatively thinking I can account for this by limiting the number of categories being sent per email and potentially including logic around EULA length.

@snipe
Copy link
Member

snipe commented Dec 11, 2025

That's an interesting approach. Breaking them out by their EULAs, so each unique EULA gets an email with one or more items in it.... I think I like that.

@marcusmoore marcusmoore marked this pull request as draft December 16, 2025 17:54
@marcusmoore
Copy link
Collaborator Author

Moving this to a draft while I hash out the potential truncation or character limit issue.

@snipe
Copy link
Member

snipe commented Jan 5, 2026

I deleted the comments from the dev meeting because I think they're ones we can address when they come up. There are for sure some things we'll still need to address, but I think this covers the majority of the use-cases. Nothing is perfect, and as we discussed on the dev meeting, some folks use us in really unusual ways - but I think we can tweak that moving forward as those scenarios arise.

@uberbrady
Copy link
Member

So here's my example, and my proposed solution (which @snipe said she hates, but, well, I should at least write it down).

Let's imagine our categories and EULA's and stuff look like this -

  • Default EULA: "You promise not to break this."
  • Laptops: "You promise not to break this, and not to pour water on it."
  • Mobile Phones: "You promise not to break this, and not to make a bunch of international calls and buy a bunch of PokeCoins with it."
  • Printers: "You promise not to break this, and not to pour water on it."
  • Scuba gear: - uses default EULA
  • Toothbrushes: - uses default EULA
  • Mythical creatures from 80's movies: "You promise not to break this, and not to pour water on it."

The thing is, with the current EULA structure, we're going to display and re-display the same EULAs to people a couple of times with our category-centric ways of handling this. So my idea was to normalize the EULAs into their own table. And then you can select which EULA you want for which category (or NULL for 'use default'? Or is that the use-default checkbox?)

With this normalized EULA, we get a few things at the same time - we might be able to store versions of a EULA, to know which one was signed? And we can 'roll up' lists of assets that are checked out to say ORDER BY eula_id and then show the EULA once-and-only-once.

@marcusmoore
Copy link
Collaborator Author

@snipe Yeah, I agree. I think we'll be okay with merging this as is and then figure things out if (as) they bubble up.

Something to consider in the future is moving the logic that groups assets by category from the mailable to the listener so you have a hook to say "is this email too long? let's fire off an email per category instead" or something similar.

@marcusmoore marcusmoore marked this pull request as ready for review January 5, 2026 23:18
@marcusmoore
Copy link
Collaborator Author

I think we'll be okay with merging this as is

I mean "merging as is" after a review of course 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bulk checkout creates separate emails for every item checked out.

3 participants